In order to avoid overloading a Gx/Sd interface with a list of packet flow detection filters which may include beyond 5 Tuples higher layer information over a Gx/Sd Diameter session set up for each user, a PCC/ADC rule sent by a PCRF to a PCEF/TDF contains an application identifier that refers to an application detection filter preconfigured in the PCEF/TDF. Since an ASP may provision, update or delete the filters from time to time, SDCI features are introduced into 3GPP, which enable the ASP to flexibly manage the application detection filters through a SCEF and a newly introduced PFDF. The PFDF is responsible for the management of PFDs (i.e. provision, modification and removal) according to the instructions received from the SCS/AS (owned by the ASP) via the SCEF, as is defined in TS 23.682, and the PFD is an extension of the application detection filter that is preconfigured in the PCEF/TDF.
According to the definition in 3GPP TS 23.203, the PFD may be retrieved by the PCEF/TDF in a pull mode from the PFDF or may be provisioned from the PFDF to the PCEF/TDF in a push mode. When the push mode is used, the PFDF distributes the PFD for each application identifier to the PCEF/TDF, which enables access to the application. There have been three methods to provision the PFD from the PFDF to the PCEF/TDF:
(1) Push of the whole PFDF state according to an operator configuration in the PFDF (e.g., provision per day according to the operator configuration);
(2) Selectively push of an ASP change in the PFD set (i.e. the ASP changes the PFD set while the operator configuration defines when to push);
(3) Selectively push of the ASP change in the PFD set according to the ASP request (i.e. the ASP indicates to push changes in the PFD set within a time interval indicated by an allowed delay.)
When the pull mode is used, at the time a PCC/ADC Rule with an application identifier for which PFDs are not available is activated or provisioned, the PCEF/TDF requests all PFDs for that application identifier from the PFDF. The PFDs retrieved for the application identifier from the PFDF may be cached in the PCEF/TDF with an associated caching timer to control how long the PFDs are valid. When the caching timer elapses, if there are still active PCC/ADC rules that refer to the corresponding application identifiers, the PCEF/TDF reloads the PFDs from the PFDF.
However, there are multiple problems in such process:
Problem 1: When the pull mode is used alone, if PFDs stored in the PFDF are modified by the ASP, they can't be applied in the PCEF/TDF immediately for the application detection until the caching timer in the PCEF/TDF expires.
Problem 2: When the push mode is used alone, if PFDs stored in the PFDF are modified by the ASP, the PFDF has to push all the changed PFDs to all the PCEF/TDFs that enable access to those applications, which may lead to a high workload and storage in the PCEF/TDF, even if some potentially impacted application sessions are not alive yet. Since the operators have claimed big concern of the PFD storage in the PCEF/TDF when SDCI study is initiated, the problem can't be ignored. In addition, the payload of Gw/Gwn interface between PFDF and PCEF/TDF is also highly increased.
For problem 1, the prior art has provided two options: (1) the caching timer can be set very short, so that it won't miss any change of PFDs stored in the PFDF, however, it will increase the signaling between the PFDF and the PCEF/TDF. (2) It is proposed in the 3GPP TS23.203 that “within one PLMN, a combination of the pull and push mode may be supported if the feature is supported.” However, such problem 2 is then introduced. In addition, if the push mode is requested with an allowed delay that is larger than the time interval for the pull mode to fetch the PFDs, some unnecessary signaling is introduced, i.e., the updated PFDs have already been fetched by the PCEF/TDF within the allowed delay.
For problem 2, there's no standardized solution so far. It might be resolved by the pre-configuration, i.e., the PFDF may be configured to provision the PFDs pertaining to a specific APN to the PCEF/TDF which supports the APN. However, the granularity of APN is far from enough to differentiate various ongoing application sessions which the updated PFDs would be applied to, and the PCEF/TDF has to store many PFDs which are not used within the caching timer. The PCEF/TDF should remove the PFDs which are not used as soon as possible after receiving all of them to save the storage.
Therefore, in order to solve the above problems, there is a need to improve the way of handling the transfer of updated PFDs.